Status:  U
Message-ID: <D7B9C7AE2156463FA7EB18F57BDD7CDB@P6X58D>
From: "Lothan" <lothan@newsguy.com>
To: "CoCoList for Color Computer Enthusiasts" <coco@maltedmedia.com>
References: <20110526095217.GA15977@brawl.fslf.org><874216FA43694C15965E5BA5737019D7@Shasta>
	<20110526205718.GE23032@brawl.fslf.org>
In-Reply-To: <20110526205718.GE23032@brawl.fslf.org>
Date: Thu, 26 May 2011 21:11:05 -0400
MIME-Version: 1.0
Importance: Normal
Subject: Re: [Coco] cprep19a.lzh upload
Precedence: list
Reply-To: CoCoList for Color Computer Enthusiasts <coco@maltedmedia.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: coco-bounces@maltedmedia.com
Errors-To: coco-bounces@maltedmedia.com

If I remember correctly, string constants are kept pretty much wherever they 
are defined in the code, so the location depends on the order of the 
modules/libraries being linked. I think cstart.r is linked first by cc1/cc2 
so it's right after the module header.

Globaql initialization data for other data types (and for some strings) is 
stored at the tail end of the executable. I'm looking at the disassembly for 
ansifront for example and I see "noname.c" is is in the initialization 
section at the end of the executable while all the other strings are in the 
middle of the code.

Look in cstart.a and you'll see at csta10 it copies the dp-data (direct page 
initialization data) from the executable into the direct page. At csta15 it 
copies the non-dp data from the end of the executable to the memory area 
right after the direct page. It then clears the bss data, relocates the 
data-text references (pointers to stuff in the executable module like 
function pointers and pointers to string constants), relocates the data-data 
references (pointers to stuff in the data area like pointers to structs), 
resets the stack, and processes the command-line arguments. The references 
are relocated because the C compiler/linker stores the pointers based on 
zero offsets, so it has to calculate the final addresses based on the 
location of the module and data area in memory.

-----Original Message----- 
From: Willard Goosey
Sent: Thursday, May 26, 2011 4:57 PM
To: CoCoList for Color Computer Enthusiasts
Subject: Re: [Coco] cprep19a.lzh upload

On Thu, May 26, 2011 at 08:13:08AM -0700, Stephen H. Fischer wrote:
>
> I now wonder how to make sure it is near the start of the binary. Part of
> Globals?

I believe global initialized data is right after the module header, yes.
That starts getting to be a complicated question about how rlink does
its magic, and I've never gone there. ;-)

Willard
-- 
Willard Goosey  goosey@sdc.org
Socorro, New Mexico, USA
I search my heart and find Cimmeria, land of Darkness and the Night.
  -- R.E. Howard

--
Coco mailing list
Coco@maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco 


--
Coco mailing list
Coco@maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco